1. Field
The present invention relates to improved methods for processing requests and sending data in a bus architecture. The present invention further relates to an improved bus architecture for processing requests and data.
2. Related Art
As is well known, many computing systems employ architectures in which one or more master devices are connected to one or more slave devices via a bus. The master and slave devices may comprise general purpose processors, memory controllers, interface chipsets, input output devices and other integrated circuits that process data requests. More and more such bus architectures are being integrated within SoC (System on Chip) devices.
An example of such a bus architecture is shown in FIG. 1. A plurality of master devices 101 are connected via bus 103 to a plurality of slave devices 105a, 105b. In FIG. 1, slave device 105a is an internal slave apparatus and slave device 105b is an external slave apparatus. The architecture in FIG. 1 also includes arbiters 107, allocators 109 and optimisers 111a, 111b. The arbiters allow two or more master devices to be connected to one slave device. Arbitration of the priority for the bus use rights is executed by the arbiter. The allocators allow one master device to be connected to two or more slave devices. The routing of the bus traffic to the relevant slave device is performed via address decoding. If a target slave device is unavailable (for example, powered off or disabled from operation), the allocator can be informed and traffic for that slave device may be handled within the allocator. The optimisers allow the traffic for a slave device to be buffered and re-sorted to increase the efficiency of access to the slave device. They act as an intelligent buffer for the particular slave device. In FIG. 1, optimiser 111a is an internal optimiser for internal slave device 105a and optimiser 111b is an external optimiser for external slave device 105b. The optimisers in FIG. 1 are shown external to the bus. However, since the optimisers are the link between the bus and the slave device, they can be considered either as part of the bus or as part of the slave device. Typically, the input side of the optimiser upholds the bus requirements and bus protocols whereas the output side of the optimiser upholds the slave requirements. The particular architecture of a bus structure may take any number of forms and FIG. 1 is a relatively simple example. The pathways between the master devices and the slave devices can be implemented most advantageously for the master devices' access patterns and requirements.
In FIG. 1, the optimisers 111a, 111b, which function as buffers for incoming requests, are provided close to the respective slave apparatus 105a, 105b. This provides several advantages. Incoming requests may be gathered in the optimiser when the target slave apparatus has a period of unresponsiveness. This allows the requests to be ordered to improve the efficiency of the slave device access when accesses are allowed. Additional signalling is also provided from the optimisers to the master devices to warn when the buffering for a particular master device is becoming full. This enables the optimiser to cease request traffic for a particular master device, which prevents a request waiting outside the optimiser when the optimiser buffer is full. A request waiting outside the optimiser may block all other accesses to the target slave device (although buffering may be provided individually per master device), and could lead to the connecting bus structure preventing any request movement until resolution of the situation. When the buffer is becoming full and an optimiser requests a master device to cease sending traffic, there may be request traffic relating to this master device already within the bus architecture. In addition, a master device may continue to send a pre-defined number of requests after a request to cease traffic. This means that a cease indication from an optimiser must be activated at a point before the buffer fills, to ensure that there is always enough buffer space to accept the in-progress traffic.
In a bus architecture such as that shown in FIG. 1, the master devices are not required to have any specific knowledge of the slave devices which they are targeting for access. This results in the request ordering requirements expected by the master device being handled within the bus architecture. There is an expectation that requests issued by a master device will be operated in the sequence of issue. For write requests, in the current implementation, there is no feedback to the master device requesting the write, so the ordering requirement is upheld for each particular slave device target. For read requests, however, the returning data must arrive in the expected order, and so control is required to ensure this happens correctly. With an increasing number of bus architectures being integrated within SoC devices, more sophisticated bus structures are required to allow each bus to operate its traffic at the required performance levels.